In systems for validation of transaction data, a principal functionality of a rules engine is to quickly and accurately deduce whether or not a transaction is a candidate for flagging with additional identification data, and a principal functionality of a loyalty engine is to quickly and accurately track and manage entities relating to transactions. The functionalities are born out of validations by the rules engine and/or loyalty engine based on certain rules therein. Such functionalities are overly processor and memory intensive; therefore, the validations in previous rules engines and loyalty engines are done after the fact of a transaction, and applied to the original transaction data in a retroactive fashion. Alternatively, in order to compensate for the overhead, the validations in previous rules engines and loyalty engines are non-dynamic and with limited scope and function for practical use in real-time environment.
U.S. Pat. No. 6,560,592 B1 (Reid et al., 2003) discloses a multi-model computer database storage system with a integrated rules engine. In the system, rule-sets are stored in either a database or externally. U.S. Pat. No. 7,958,077 B2 (Vescovi, 2011) discloses a rules engine, in which data and programming instructions to perform functions in the rules engine are stored in mass storage. U.S. Pat. No. 7,873,560 discloses an automated transaction compliance processing system comprising a rules engine, which is connected to a rules database or other storage area containing predefined rules. All rules engines in these disclosures rely on rule-sets in external storage media instead of system memory; therefore, the rules engines in these disclosures are non-dynamic, and lack high volume and real-time capacity. US Pat. Pub. No. 20090271214 A1 (Kandasamy et al., 2009) discloses a rule engine for a health care information system. In this disclosure, the rules from a rules repository are precompiled into a binary format for run-time execution and then the compiled rules with a single rules engine are situated on a process server which is accessed by workstations. But, the rules are not compressed and optimized; therefore, the disclosure does not solve the problems in previous rules engines.
In order to create a level of modularity and nimbleness of a rules engine or a loyalty engine, it is not practical to host all active rules within the same compiled instance of the rules engine or the loyalty engine. Even with benefits provided by a compressed and optimized version, a single all-encompassing instance to service all clients' needs is not viable. In previous disclosures, rules engines or loyalty engines lack the modularity and nimbleness.
With performance sensitive software systems, such as rules engines and loyalty engines, a major constraint is hardware environment. It becomes significantly more expensive to build hardware with enterprise-level amounts of random access memory (RAM) or other similar equipment for supporting a completely cached version of a single all-encompassing instance. No previous disclosures provide solutions for this problem.
Another problem in previous validation systems for transaction data is that rules engines and/or loyalty engines do not support real-time updates. Traditionally, an outdated rules engine or loyalty engine is completely removed from a validation system before an updated one can be put into the system. Therefore, without the environment of real-time updates, the uptime capacity of the validation systems is low.